Internet Surfer 2.0

home *** CD-ROM | disk | FTP | other *** search

/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.385 < prev next >

Wrap

Text File | 1996-02-12 | 28.2 KB | 619 lines

Frequently Asked Questions (FAQS);faqs.385 FAQ lists are intended to reduce the noise level in their newsgroups that results from the repetition of the same questions, correct answers, wrong answers, corrections to the wrong answers, corrections to the corrections, debate, etc. This list should serve as a repository of the canonical "best" answers to the questions in it. The names of folks who have helped to improve this FAQ list follow the table of contents. If you know a better answer or even a slight change that improves an answer, please tell me! (Use email, please. Traffic in this group is high, and I may miss a relevant posted article.) Stan Brown, Oak Road Systems, Cleveland, Ohio, USA brown@ncoast.org Search tips =========== To search for specific topics: See the list of questions in the Contents section (immediately below) to find which article (part 2, 3, or 4) you need. Then, in that part, search for that question number. For example, while you're reading part 2 of this list, the trn newsreader command "gQ203" goes to Q203. To skip one topic and go to the next: Search for "Q" starting in column 1. In trn and similar newsreaders, the command "g^Q" does that. If your newsreader doesn't support searches, you can extract these articles to a file and use your favorite editor's search commands. Contents--part 2 of 4 ===================== section 1. General questions 101. Why won't my code work? 102. What is this newsgroup about? 103. What's the difference from comp.sys.ibm.pc.programmer? 104. What other newsgroups should I know about? section 2. Compile and link 201. What the heck is "DGROUP > 64K"? 202. How do I fix "automatic data segment exceeds 64K" or "stack plus data exceed 64K"? 203. Will Borland C code and Microsoft C code link together? 204. Why did my program bomb at run time with "floating point formats not linked"? 205. Why did my program bomb with "floating point not loaded"? 206. How can I change the stack size in Borland's C compilers? 207. What's the format of an .OBJ file? 208. What's the format of an .EXE header? 209. What's the difference between .COM and .EXE formats? section 3. Keyboard 301. How can I read a character without echoing it to the screen, and without waiting for the user to press the Enter key? 302. How can I find out whether a character has been typed, without waiting for one? 303. How can I disable Ctrl-C/Ctrl-Break and/or Ctrl-Alt-Del? 304. How can I disable the print screen function? 305. How can my program turn NumLock (CapsLock, ScrollLock) on/off? 306. How can I speed up the keyboard's auto-repeat? 307. What is the SysRq key for? 308. How can my program tell what kind of keyboard is on the system? 309. How can I tell if input, output, or stderr has been redirected? Contents--part 3 of 4 ===================== section 4. Disks and files 401. What drive was the PC booted from? 402. How can I boot from drive b:? 403. Which real and virtual disk drives are valid? 404. How can I make my single floppy drive both a: and b:? 405. Why won't my C program open a file with a path? 406. How can I redirect printer output to a file? 407. How can my program open more files than DOS's limit of 20? 408. How can I read, create, change, or delete the volume label? 409. How can I get the disk serial number? 410. What's the format of .OBJ, .EXE., .COM files? section 5. Serial ports (COM ports) 501. How do I set my machine up to use COM3 and COM4? 502. How do I find the I/O address of a COM port? 503. But aren't the COM ports always at I/O addresses 3F8, 2F8, 3E8, and 2E8? 504. How do I configure a COM port and use it to transmit data? section 6. Other hardware questions and problems 601. Which 80x86 CPU is running my program? 602. How can a C program send control codes to my printer? 603. How can I redirect printer output to a file? 604. Which video adapter is installed? 605. How do I switch to 43- or 50-line mode? 606. How can I find the Microsoft mouse position and button status? 607. How can I access a specific address in the PC's memory? 608. How can I read or write my PC's CMOS memory? 609. How can I access memory beyond 640K? section 7. Other software questions and problems 701. How can a program reboot my PC? 702. How can I time events with finer resolution than the system clock's 55 ms (about 18 ticks a second)? 703. How can I find the error level of the previous program? 704. How can a program set DOS environment variables? 705. How can I change the switch character to - from /? 706. Why does my interrupt function behave strangely? 707. How can I write a TSR (terminate-stay-resident) utility? 708. How can I write a device driver? 709. What can I use to manage versions of software? 710. What's this "null pointer assignment" after my C program executes? Contents--part 4 of 4 ===================== section A. Downloading A01. What is garbo? What is wustl? A02. What are Simtel and "mirror sites"? What good are they? A03. Where do I find program <mumble>? A04. How can I check Simtel or garbo before I post a request for a program? A05. How do I download and decode a program I found? A06. Where is UUDECODE? A07. Why do I get errors when extracting from a ZIP file I downloaded? section B. Vendors and products B01. How can I contact Borland? B02. How can I contact Microsoft? B03. What's the current version of PKZIP? B04. What's in Borland Pascal/Turbo Pascal 7.0? B05. What's in Microsoft C/C++ 7.0? section C. More information C01. Are there any good on-line references for PC hardware components? C02. Are there any good on-line references for PC interrupts? C03. What and where is "Ralf Brown's interrupt list"? C04. Where can I find lex, yacc, and language grammars? C05. What's the best book to learn programming? C06. Where are FAQ lists archived? C07. Where can I get the latest copy of this FAQ list? Acknowledgements ================ Many articles posted in comp.os.msdos.programmer sparked ideas or provided information for the first version of this list. Though I am responsible for any errors, thanks are due to the following for posted articles or private email that I used in subsequent editions: Jamshid Afshar, Mark Aitchison, Sanjay Aiyagari, George Almasi, Aaron Auseth, Preston Bannister, Denis Beauregard, Mike Black, Glynn Brooks, Paul Brooks, Ralf Brown, Shaun Burnett, Raymond Chen, Alan Drew, Paul Ducklin, Gary Dueck, Roland Eriksson, Markus Fischer, George Forsman, B.Haible, Klaus Hartnegg, Kris Heidenstrom, Joel Hoffman, Joe Huffman, Michael Holin, Mike Iarrobino, Ajay Kamdar, Everett Kaser, Jen Kilmer, Reinhard Kirchner, Dave Kirsch, Sidney Markowitz, Jim Marks, Dimitri Matzarakis, Ken McKee, Tom Milner, Duncan Murdoch, Steve Murphy, Mert Nickerson, David Nugent, Keith Petersen, Karl Riedling, Arthur Rubin, Gerald Ruderman, Timo Salmi, Tapio Sand, John Schmid, Ajay Shah, Tom Swingle, Anders Thulin, Curt Tilmes, Ya-Gui Wei, Joe Wells, Gregory Youngblood, khill@vax1.umkc.edu, rujo@extern.uio.no New contributors this month: Paul Ducklin, Mike Iarrobino, Duncan Murdoch, Anders Thulin, Curt Tilmes, rujo@extern.uio.no Legalistic stuff ================ This article is not in the public domain, but it may be redistributed so long as this notice, and the information on obtaining the latest copy of this list, are retained. The code fragments may be used freely; credit would be appreciated but is not required. Copyright (C) 1992 Stan Brown, Oak Road Systems. All rights reserved. THERE IS NO WARRANTY ON THE CODE. I have tested all the code included below, but your machine may not work the same as mine, and my testing may not be perfect. (Except where otherwise noted, I tested the code with both BC++ 2.0 and MSC 5.0.) The mention of particular books or programs must not be construed to reflect unfavorably on any that are not mentioned. (continued in part 2) -- Stan Brown, Oak Road Systems brown@Ncoast.ORG Cleveland, Ohio, USA Xref: bloom-picayune.mit.edu comp.os.msdos.programmer:18889 news.answers:4712 Path: bloom-picayune.mit.edu!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!mcsun!uknet!doc.ic.ac.uk!agate!ames!sun-barr!cs.utexas.edu!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!ncoast!brown From: brown@NCoast.ORG (Stan Brown) Newsgroups: comp.os.msdos.programmer,news.answers Subject: comp.os.msdos.programmer FAQ part 2 of 4 Message-ID: <msdos-faq.921220.2@NCoast.ORG> Date: 20 Dec 92 20:13:14 GMT Expires: Wed, 3 Feb 1993 20:13:14 GMT References: <msdos-faq.921220.1@NCoast.ORG> Followup-To: comp.os.msdos.programmer Organization: Oak Road Systems, Cleveland Ohio USA Lines: 589 Approved: news-answers-request@MIT.Edu Supersedes: <msdos-faq.921205.2@NCoast.ORG> Archive-name: msdos-programmer-faq/part2 Last-modified: 20 December 1922 (continued from part 1) (no warranty on the code or information) If the posting date is more than six weeks in the past, see instructions at the end of this article for how to get an updated copy. Copyright (C) 1992 Stan Brown, Oak Road Systems section 1. General questions ============================ Q101. Why won't my code work? First you need to try to determine whether the problem is in your use of the programming language or in your use of MSDOS and your PC hardware. (Your manual should tell you which features are standard and which are vendor- or MSDOS- or PC-specific. You _have_ read your manual carefully, haven't you?) If the feature that seems to be working wrong is something related to your PC hardware or to the internals of MS-DOS, this group is the right place to ask. (Please check this list first, to make sure your question isn't already answered.) On the other hand, if your problem is with the programming language, the comp.lang hierarchy (including comp.lang.pascal and comp.lang c) is probably a better resource. Please read the other group's FAQ list thoroughly before posting. (These exist in comp.lang.c, comp.lang.c++, comp.lang.modula3, comp.lang.lisp, comp.lang.perl; they may exist in other groups as well.) It's almost never a good idea to crosspost between this group and a language group. Before posting in either place, try to make your program as small as possible while still exhibiting the bad behavior. Sometimes this alone is enough to show you where the trouble is. Also edit your description of the problem to be as short as possible. This makes it look more like you tried to solve the problem on your own, and makes people more inclined to try to help you. When you do post a question, it's good manners to say "email please; I'll post a summary." Then everybody else in the group doesn't have to read ten virtually identical responses. Of course, then you have to follow through. A summary is not simply pasting together all the email you received. Instead, write your own (brief) description of the solution: this is the best way to make sure you really understand it. Definitely don't repost people's cute signatures. Q102. What is this newsgroup about? comp.os.msdos.programmer (comp.sys.ibm.pc.programmer until September 1990) concerns programming for MS-DOS systems. The article "USENET Readership report for Nov 92" in news.lists shows 42,000 readers of this newsgroup worldwide. Traffic was 1090.7 Kbytes (exclusive of crossposts), comprised in 611 articles. Much of our traffic is about language products (chiefly from Borland and Microsoft). More programming topics focus on C than on any one other language. Since most MS-DOS systems run on hardware that is roughly compatible with the IBM PC, on Intel 8088, 80188, or 80x86 chips, we tend to get a lot of questions and answers about programming other parts of the hardware. Q103. What's the difference from comp.sys.ibm.pc.programmer? c.s.i.p.programmer is the old name of comp.os.msdos.programmer, and has been obsolete since September 1990. However, many systems have not removed the old group, or have removed it but aliased it to the new name. This means that some people still think they're posting to c.s.i.p.programmer even though they're actually posting to c.o.m.programmer. You can easily verify the non-existence of c.s.i.p.programmer by reference to the "List of Active Newsgroups" posted to news.groups. It's available as /pub/usenet/news.answers/active-newsgroups/part1 from the archives (see "Where are FAQ lists archived?" in section C, "More information"). Q104. What other newsgroups should I know about? Your best bet is to read the periodic information postings in the comp.binaries.ibm.pc newsgroup. Specially helpful articles: Using the comp.binaries.ibm.pc.d groups Beginner's guide to binaries Starter kit About archives and archivers Please wait for these articles to come around; don't post a request. Also check out news.announce.newusers, even if you're not a new user. You may be surprised how much useful information is in the monthly postings there. Lots of old-timers also get useful stuff from news.newusers.questions, especially the periodic postings. Remember that it's good manners to subscribe to any newsgroup and read it for a while before you post a question. When you post, it's also good manners to ask for replies to be emailed and then to post a summary, which you've edited down to the absolute minimum size. You may also be interested in the following newsgroups. Caution: Some of them have specialized charters; you'll probably get (and deserve) some flames if you post to an inappropriate group. - misc.forsale.computers and misc.forsale.computers.pc-clone are where you post notices of equipment, software, or computer books that you want to sell. Please don't post or crosspost those notices to comp.os.msdos.programmer. - comp.os.ms-windows.programmer.tools and ...misc (formerly part of comp.windows.ms.programmer): Similar to this group, but focus on programming for the MS-Windows platform. - comp.sys.ibm.pc.hardware is for more hardware-oriented discussions of the machines that run DOS. - comp.binaries.ibm.pc.wanted: AFTER you have looked in the other groups, this is the place to post a request for a particular binary program. - comp.binaries.msdos.announce (moderated) explains how to use the archive sites, especially garbo and Simtel, and lists files uploaded to them. Discussions belong in comp.binaries.msdos.d, which replaced comp.binaries.ibm.pc.archives. - comp.binaries.ibm.pc.d is for discussions about programs posted in comp.binaries.ibm.pc, and only those programs. This is a good place to report bugs in the programs, but not to ask where to find them (see cbip.wanted, above). cbip.d is NOT supposed to be a general PC discussion group. - comp.sources.misc: a moderated group for source code for many computer systems. It tends to get lots of Unix stuff, but you may also pick up some DOS-compatible code here. - alt.sources: an unmoderated group for source code. Guidelines are posted periodically. - Turbo Vision is a mailing list, not a newsgroup; send email to listserv@vtvm1.cc.vt.edu if you want to subscribe. section 2. Compile and link =========================== Q201. What the heck is "DGROUP > 64K"? DGROUP is a link-time group of data segments, and the compiler typically generates code that expects DS to be pointing to DGROUP. (Exception: Borland's huge model has no DGROUP.) Here's what goes into DGROUP: - tiny model (all pointers near): DGROUP holds the entire program. - small and medium models (data pointers near): DGROUP holds all globals and static variables including string literals, plus the stack and the heap. - large, compact, and huge models in Microsoft (data pointers far): DGROUP holds only initialized globals and static variables including string literals, plus the stack and the near heap. - large and compact models in Borland (data pointers far): DGROUP holds initialized and uninitialized globals and static variables including string literals, but not the stack or heap. - huge model in Borland (data pointers far): there is no DGROUP, so the 64K limit doesn't apply. In all of the above, which is to say all six models in Microsoft C and all but huge in Borland C, DGROUP is limited to 64K including string literals (which are treated as static data). This limitation is due to the Intel CPU's segmented architecture. See the next Q for possible remedies. For more information, see topics like "memory models" and "memory management" in the index of your compiler manual. Also see TI738.ASC in PD1:<MSDOS.TURBO-C>BCHELP10.ZIP at Simtel for an extended general discussion of memory usage in Borland C programs, of which much applies to any C compiler in DOS. Q202. How do I fix "automatic data segment exceeds 64K" or "stack plus data exceed 64K"? These messages are a variation of "DGROUP > 64K". For causes, please see the preceding Q. If you get this error in tiny model, your program is simply too big and you must use a different memory model. If you get this link error in models S, C, M, L, or Microsoft's H, there are some things you can do. (This error can't occur in Borland's huge model.) If you have one or two big global arrays, simply declare them far. The compiler takes this to mean that any references to them will use 32-bit pointers, so they'll be in separate segments and no longer part of DGROUP. Or you can use the /Gt[number] option with Microsoft or -Ff[=size] with Borland C++ 2.0 and up. This will automatically put variables above a certain size into their own segments outside of DGROUP. Yet another option is to change global arrays to far pointers. Then at the beginning of your program, allocate them from the far heap (_fmalloc in Microsoft, farmalloc in Borland). Finally, you can change to huge model (with Borland compilers, not Microsoft). Borland's H model still uses far pointers by default, but "sets aside the [64K] limit" and has no DGROUP group, according to the BC++ 2.0 Programmer's Guide. Microsoft's H model does use huge data pointers by default but retains DGROUP and its 64K limit, so switching to the H model doesn't buy you anything if you have DGROUP problems. Q203. Will Borland C code and Microsoft C code link together? Typically this question is asked by someone who owns compiler A and is trying to write code to link with a third-party library that was compiled under compiler B. The answer to the question is, Not in general. Here are some of the reasons: - "Helper" functions (undocumented functions for stack checking, floating-point arithmetic, and operations on longs) differ between the two compilers. - The compilers may embed instructions in the object code that tell the linker to look for their own run-time libraries. Those problems will generate link-time errors. Others may not show up until run time: - Borland's compact, large, and huge models don't assume DS=SS, but Microsoft's do. The -Fs option on the Borland compiler, or one of the /A options on Microsoft, should take care of this problem -- once you know that's what's going on. - Check conventions for ordering and packing structure members, and for alignment of various types on byte, word, paragraph, or other boundaries. Again, you can generally adjust your code to match if you know what conventions were used in compiling the "foreign" libraries. - Check the obvious and make sure that your code was compiled under the same memory model as the code you're trying to link with. (That's necessary, but no guarantee. Microsoft and Borland don't use exactly the same conventions for segments and groups, particularly in the larger memory models.) That said, there are some circumstances where you can link hybrids. Your best chance of success comes if you avoid longs and floating point, use only 16-bit pointers, suppress stack checking, and specify all libraries used in the link. Q204. Why did my program bomb at run time with "floating point formats not linked"? First, is that the actual message, or did it say "floating point not loaded"? If it was the latter, see the next Q. You're probably using a Borland compiler for C or C++ (including Turbo C and Turbo C++). Borland's compilers try to be smart and not link in the floating-point (f-p) library unless you need it. Alas, they all get the decision wrong. One common case is where you don't call any f-p functions, but you have %f or other f-p formats in scanf/printf calls. The cure is to call an f-p function, or at least force one to be present in the link. To do that, define this function somewhere in a source file but don't call it: static void forcefloat(float *p) { float f = *p; forcefloat(&f); } It doesn't have to be in the module with the main program, as long as it's in a module that will be included in the link. A new solution for Borland C++ 3.0 was posted, but I don't own the product and have not been able to verify it. Insert these statements in your program: extern unsigned _floatconvert; #pragma extref _floatconvert Q205. Why did my program bomb with "floating point not loaded"? That is Microsoft C's run-time message when the code requires a numeric coprocessor but your computer doesn't have one installed. If the program is yours, relink it using the xLIBCE or xLIBCA library (where x is the memory model). Q206. How can I change the stack size in Borland's C compilers? In Turbo C, Turbo C++, and Borland C++, you may not find "stack size" in the index but the global variable _stklen should be there. The manual will instruct you to put a statement like extern unsigned _stklen = 54321U; in your code, outside of any function. You must assign the value right in the extern statement; it won't work to assign a value at run time. (The "extern" in this context isn't ANSI C and ought not to be required, but the above statement is a direct quote from the Library Reference manual of Borland C++ 2.0.) The linker may give you a duplicate symbol warning, which you can ignore. Q207. What's the format of an .OBJ file? Here's what I've been told, though I have verified any of these references myself: - base .OBJ format: Intel's document number #121748-001, {8086 Relocatable Object Module Formats}. (Note however that both Microsoft and Borland formats have extended the .OBJ format.) - Microsoft-specific .OBJ formats: a "Microsoft OMF Specification" (document number ??), as well as a section in the MS-DOS encyclopedia. - A "tutorial on the .OBJ format" comes with the VAL experimental linker, which is VAL-LINK.ARC in PD1:<MSDOS.PGMUTL> at Simtel. If you have specific references, either to fpt-able documents or to published works (author, title, order number or ISBN), please email them to brown@ncoast.org for inclusion in the next edition of this list. Q208. What's the format of an .EXE header? See pages 349-350 of {PC Magazine}'s June 30, 1992 issue (xi:12) for the old and new formats. For a more detailed layout, look under INT 21 function 4B in Ralf Brown's interrupt list. Ralf Brown's list includes extensions for Borland's TLINK and Borland debugger info. Among the books that detail formats of executable files are {DOS Programmer's Reference: 2d Edition} by Terry Dettman and Jim Kyle, ISBN 0-88022-458-4; and {Microsoft MS-DOS Programmer's Reference}, ISBN 1-55615-329-5. Q209. What's the difference between .COM and .EXE formats? To oversimplify: a .COM file is a direct image of core, and an .EXE file will undergo some further relocation when it is run (and so it begins with a relocation header). A .COM file is limited to 64K for all segments combined, but an .EXE file can have as many segments as your linker will handle and be as large as RAM can take. The actual file extension doesn't matter. DOS knows that a file being loaded is in .EXE format if its first two bytes are MZ or ZM; otherwise it is assumed to be in .COM format. For instance, I am told that DR-DOS 6.0's COMMAND.COM is in .EXE format. section 3. Keyboard =================== Q301. How can I read a character without echoing it to the screen, and without waiting for the user to press the Enter key? The C compilers from Microsoft and Borland offer getch (or getche to echo the character); Turbo Pascal has ReadKey. In other programming languages, load 8 in register AH and execute INT 21; AL is returned with the character from standard input (possibly redirected). If you don't want to allow redirection, or you want to capture Ctrl-C and other special keys, use INT 16 with AH=10; this will return the scan code in AH and ASCII code (if possible) in AL, except that AL=E0 with AH nonzero indicates one of the grey "extended" keys was pressed. (If your BIOS doesn't support the extended keyboard, use INT 16 function 0 not 10.) Q302. How can I find out whether a character has been typed, without waiting for one? In Turbo Pascal, use KeyPressed. Both Microsoft C and Turbo C offer the kbhit( ) function. All of these tell you whether a key has been pressed. If no key has been pressed, they return that information to your program. If a keystroke is waiting, they tell your program that but leave the key in the input buffer. You can use the BIOS call, INT 16 function 01 or 11, to check whether an actual keystroke is waiting; or the DOS call, INT 21 function 0B, to check for a keystroke from stdin (subject to redirection). See Ralf Brown's interrupt list. Q303. How can I disable Ctrl-C/Ctrl-Break and/or Ctrl-Alt-Del? You can download the file PD1:<MSDOS.KEYBOARD>CADEL.ZIP from Simtel. It contains a TSR to disable those keys, with source code in ASM. To disable only Ctrl-Alt-Del (actually, to change the boot keys to leftShift-Alt-Del), use DEBOOT.COM. Along with KEYKILL.COM, which lets you disable up to three keys of your choice, it is at Simtel in the file PD1:<MSDOS.KEYBOARD>KEYKILL.ARC. C programmers who simply want to make sure that the user can't Ctrl-Break out of their program can use the ANSI-standard signal( ) function; the Borland compilers also offer ctrlbrk( ) for handling Ctrl-Break. However, if your program uses normal DOS input, the characters ^C will appear on the screen when the user presses Ctrl-C or Ctrl-Break. There are many ways to work around that, including: use INT 21 function 7, which allows redirection but doesn't display the ^C (or echo any other character, for that matter); or use INT 16 function 0 or 10; or call _bios_keybrd( ) in MSC or bioskey( ) in BC++; or hook INT 9 to discard Ctrl-C and Ctrl-Break before the regular BIOS keyboard handler sees them; etc., etc. You should be aware that Ctrl-C and Ctrl-Break are processed quite differently internally. Ctrl-Break, like all keystrokes, is processed by the BIOS code at INT 9 as soon as the user presses the keys, even if earlier keys are still in the keyboard buffer: by default the handler at INT 1B is called. Ctrl-C is not special to the BIOS, nor is it special to DOS functions 6 and 7; it _is_ special to DOS functions 1 and 8 when at the head of the keyboard buffer. You will need to make sure BREAK is OFF to prevent DOS polling the keyboard for Ctrl-C during non-keyboard operations.